Columbia Kermit/kermit.zip/newsgroups/misc.19950329-19950528/[e-mail]_Wed Apr 19 14:43:43 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05709
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Thu, 20 Apr 1995 00:55:50 -0400
Received: by apakabar.cc.columbia.edu id AA23725
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 20 Apr 1995 00:55:48 -0400
Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: A problem with PREFIX'ed characters
Message-Id: <[e-mail]>
Date: 19 Apr 95 20:43:43 MDT
References: <3n3r18$[e-mail]>
Organization: Utah State University
Lines: 49
Apparently-To: [e-mail]

In article <3n3r18$[e-mail]>, [e-mail] (Rusty Haddock) writes:
>
>    Please let me call the Kermit maintainers' attention to what appears
> to have been a problem for me when using the latest version of MS-DOS
> Kermit with C-Kermit 5A(190) on a Sun.  This problem has to do with the
> differences in which control characters that each version of Kermit can
> set/unset as prefixed.  In C-Kermit, the command "set control unprefix
> all" sets the control characters ASCII 1-31,127-159, and 255 as being
> unprefixed.  Oddly(?) enough the NULL character, ASCII 0, is always listed
> as being prefixed.  That cannot be changed, so it appears.  Hrumph!
>
>    Now let's look at the current version of MS-DOS Kermit, v3.14.
> "set control unprefix all" sets even the NULL character as being
> unprefixed yet the user can not tell Kermit "set control unprefix 127" nor
> "set control unprefix 255" without an error message as one could do in
> C-Kermit.
>
>    For me, performing "set control unprefix all" to both C-Kermit and
> MS-DOS Kermit before a *binary* file transfer appears to causing the
> file not to be transferred because of the differences in what each
> version of Kermit considers "all".   Is this something that needs to
> be coordinated between the C-Kermit and MS-DOS Kermit maintainers?
> To me, both versions appear to be incorrect in that if I request all
> characters to be unprefixed, then by golly I should get that for ALL
> 256 characters.  Maybe I've missed something here....
--------------
    Yup. Telnet for one thing. When operating across Telnet one must
send 0xff (255 decimal) as data by sending 255 255; that's the IAC Telnet
escape code. Add parity, as we can do, and that exception includes 127
decimal. Rather than making a special set of code to deal with doubling
only for Telnet, and consequently slowing down transfers, we simply don't
unprefix it.
    Both 127 and 0 are often treated as padding throwaways by many
systems, so we try to avoid getting into warm water by using them. C
strings and functions applied to them get into all kinds of trouble with
0 as data since it's also a string terminator. Thus C Kermit prefers to
avoid those problems by not using bare 0 as data.
    Both MSK and CK should work just fine with mixed unprefixed
sets, PROVIDED the comms link as a whole tolerates the treatment. The
receivers in both programs are ready to absorb bare control codes from
the other side no matter which codes it sends unprefixed the other way.
    The difference in performance between unprefixing, or not, the very
last possible control code is normally far too small to measure in practice.
Most likely your choice of unprefixing "all" has simply revealed troubles
in the comms pathway, as we strongly warn every time the unprefixing topic
arises. Finding the sensitive codes is up to you since a) we don't know
your equipment, and b) there isn't any foolproof way of finding out on the
fly.
    Joe D.